Determining the status of a device through use of a publisher/subscriber interface

ABSTRACT

A publish/subscribe interface is used to enable a non-publish/subscribe first system (such as an IP network device) to obtain status information about a publish/subscribe device that cannot be pinged by the first system. The first system sends a status request to a domain name server associated with a system known to include the publish/subscribe device. The status request includes a domain name for the publish/subscribe device. Topic space maintained by a message broker in the publish/subscribe system includes status topics associated with publish/subscribe devices. The status topics contents reflect the current availability of the associated publish/subscribe device. The domain name is mapped to a status topic associated to the publish/subscribe device identified in the status request and the contents of that status topic are retrieved. If the contents have a first value, a “good” IP address is returned to the first system. If the contents have the second value, a “bad” IP address is returned. The return address is used in ping messages. If the ping operation succeeds, it is concluded the publish/subscribe device is online. If the ping operation fails, it is concluded that the publish/subscribe device is off-line.

BACKGROUND OF THE INVENTION

The present invention relates to determining the status of a devicethrough use of a publisher/subscriber (pub/sub) interface.

Publish/subscribe data processing systems have become very popular as away of distributing data messages. Publishers are not concerned withwhere their publications are going, and subscribers are not interestedin where the messages they receive have come from. Instead, a messagebroker typically assures the integrity of the message source, andmanages the distribution of the message according to the subscriptionsregistered in the broker.

Publishers and subscribers may interact with a network of brokers, eachof which propagates subscriptions and forwards publications to otherbrokers within the network. When the term “broker” is used, it should betaken as encompassing a single broker or multiple brokers workingtogether in a network.

FIG. 1 illustrates a typical publish/subscribe data processing systemaccording to the prior art. A message broker 15 has an input mechanism20 which may be, for example, an input queue or a synchronous input nodeby which messages are input when they are sent by publishers, such aspublishers 5,10 to the message broker. A published message is fetchedfrom the input mechanism by a controller 40 and processed to determine,among other things, to which subscribers, for example, subscribers 60,65, 70, the message should be sent.

The use of topics is a key to the delivery of messages from publishersto subscribers. When a subscriber registers, that subscriber mustspecify a delivery mechanism by which it wants to receive messages andmust define the types of messages it wishes to receive; that is, thetopics. A subscriber can, for example, specify that it wishes to receivemessages including a topic string such as “employee/salary”. The brokeruses a matching engine 30 to attempt to match a published message havinga particular topic string with subscribers who have indicated they wantto receive messages including that topic string. When a match is found,the message is forwarded to the subscriber via an output mechanism 50.While the drawing shows a message broker having only a single inputmechanism and a single output mechanism to simplify the description, amessage broker will typically support multiple input and outputmechanisms.

It is common practice in publish/subscribe messaging environments tomake use of a particular kind of topic, a status topic, in the messagebroker to retain data indicative of the availability of a pub/sub systemor device. The term “device” should be construed as encompassingsoftware applications running on hardware systems. The deviceavailability data may be implemented as a “retained” publication,indicating the current status of a client. Client status is updated whena publish/subscribe client comes online and reports its status or whenit goes offline.

While broker-maintained device availability data is useful inpublisher/subscriber systems, such data has not been available todevices that do not implement a publisher/subscriber interface. A commonexample of a network device that has not been able to make use ofpublisher/subscriber device availability data is a network deviceoperating in an IP (Internet Protocol) network.

IP devices typically attempt to discover the availability of otherdevices through the execution of a PING process. In a PING process, afirst system attempts to discover the availability of a second system bysending several PING messages to the second system, that may beidentified in the messages either by an alphanumeric domain name ornumeric IP address. If the second system is capable of responding, itresponds to each PING message. Each response echoes the second system'sIP address and contains a response time value. If the second system isoff-line or otherwise unreachable, PING process software in the firstsystem will time out, indicating failure to reach the second system.

FIG. 2 is a graphical representation of a conventional PING operationperformed in an IP network. An IP device 80 attempts to PING deviceidentified by the alphanumeric domain name “A.mqtt.org”. In an IPnetwork, messages are not sent directly to the device when the devicehas been identified only by its alphanumeric domain name. Device 80'srequest is sent to a local domain name server (DNS) 90 that attempts toresolve the “A.mqtt.org” domain name to a numeric IP address; e.g.,1.2.3.4. If the local domain name server is unable to resolve the domainname to an IP address, it directs device 80 to a remote domain nameserver 95 having assigned responsibility for the specified domain (e.g.mqtt.org). DNS 95 may resolve “A.mqtt.org” to a numeric IP address(e.g., 1.2.3.4) using an IP address mapping table and then inform device80 of the numeric IP address to which the PING messages should berouted. When the PING messages reach device “A.mqtt.org”, that devicewill respond if it is online. Otherwise, the PING process at device 80will time out, indicating A.mqtt.org is not reachable.

Publish/subscribe devices may be behind a company firewall and cannot bePINGed directly to determine their status. Further, somepublish/subscribe devices can only be reached via a publish/subscribemechanism on a network which does not include the ability to respond toPING requests (for example, a non-IP network).

BRIEF SUMMARY OF THE INVENTION

The invention may be implemented as a method for enabling a firstnetwork device to use a PING process to determine whether a secondnetwork device is online or off-line where the first device cannotdirectly contact the second device. A status request is received fromthe first device at a domain name server. A determination is made at thedomain name server whether the second device is online or off-line. Ifthe second device is online, a first network address is returned to thefirst network device. If the second device is off-line, a second networkaddress is returned to the first network device. When the first networkaddress is later used in a PING process, the responses to the PING willindicate the second device. When the second network address is used, thePING process will timeout, indicating the second device is unavailable.

The invention may also be implemented as a computer program product forenabling a first network device to determine whether a second networkdevice is online or off-line. The computer program product includes acomputer usable medium embodying program code that receives a requestfrom the first device for the status of the second device and thatdetermines whether the second device is online or off-line. A computerprogram product further includes program code that causes a firstnetwork address to be returned to the first device if it is determinedthat the second device is online and a second network address to bereturned to the first device if it is determined that the second deviceis off-line.

Finally, the invention may be implemented as an apparatus for enablingthe first network device to determine whether a second network device isonline or off-line where the first device cannot directly contact thesecond device with a status query. The apparatus includes a receivercomponent that receives the status request from the first device. Thestatus request includes a second device identifier. The apparatus alsoincludes a data storage component for storing status data and themapping component for mapping the second device identifier to a datastorage component location associated with the second device. A statusquery component obtains data stored in the data storage location. Anaddress returning component returns the first network address if theobtained data has a first value or second address to the obtained dataand the second value.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

FIG. 1 illustrates a prior art publish/subscribe messaging environment.

FIG. 2 is a graphical overview of a process for determining theavailability of the remote system using domain name servers and aconventional PING operation.

FIG. 3 is a functional block diagram of a system for implementing thepresent invention using a publisher/subscriber system interface.

FIG. 4 is a flowchart of basic operations performed in the systemillustrated in FIG. 3.

FIG. 5 is a flow chart of steps that are performed at a requestingsystem to complete a status query through use of a publish/subscribeinterface.

DETAILED DESCRIPTION OF THE INVENTION

As will be appreciated by one skilled in the art, the present inventionmay be embodied as a method, system, or computer program product.Accordingly, the present invention may take the form of an entirelyhardware embodiment, an entirely software embodiment (includingfirmware, resident software, micro-code, etc.) or an embodimentcombining software and hardware aspects that may all generally bereferred to herein as a “circuit,” “module” or “system.” Furthermore,the present invention may take the form of a computer program product ona computer-usable storage medium having computer-usable program codeembodied in the medium.

Any suitable computer usable or computer readable medium may beutilized. The computer-usable or computer-readable medium may be, forexample but not limited to, an electronic, magnetic, optical,electromagnetic, infrared, or semiconductor system, apparatus, device,or propagation medium. More specific examples (a non-exhaustive list) ofthe computer-readable medium would include the following: an electricalconnection having one or more wires, a portable computer diskette, ahard disk, a random access memory (RAM), a read-only memory (ROM), anerasable programmable read-only memory (EPROM or Flash memory), anoptical fiber, a portable compact disc read-only memory (CD-ROM), anoptical storage device, a transmission media such as those supportingthe Internet or an intranet, or a magnetic storage device. Note that thecomputer-usable or computer-readable medium could even be paper oranother suitable medium upon which the program is printed, as theprogram can be electronically captured, via, for instance, opticalscanning of the paper or other medium, then compiled, interpreted, orotherwise processed in a suitable manner, if necessary, and then storedin a computer memory. In the context of this document, a computer-usableor computer-readable medium may be any medium that can contain, store,communicate, propagate, or transport the program for use by or inconnection with the instruction execution system, apparatus, or device.The computer-usable medium may include a propagated data signal with thecomputer-usable program code embodied therewith, either in baseband oras part of a carrier wave. The computer usable program code may betransmitted using any appropriate medium, including but not limited tothe Internet, wireline, optical fiber cable, RF, etc.

Computer program code for carrying out operations of the presentinvention may be written in an object oriented programming language suchas Java, Smalltalk, C++ or the like. However, the computer program codefor carrying out operations of the present invention may also be writtenin conventional procedural programming languages, such as the “C”programming language or similar programming languages. The program codemay execute entirely on the user's computer, partly on the user'scomputer, as a stand-alone software package, partly on the user'scomputer and partly on a remote computer or entirely on the remotecomputer or server. In the latter scenario, the remote computer may beconnected to the user's computer through a local area network (LAN) or awide area network (WAN), or the connection may be made to an externalcomputer (for example, through the Internet using an Internet ServiceProvider).

The present invention is described below with reference to flowchartillustrations and/or block diagrams of methods, apparatus (systems) andcomputer program products according to embodiments of the invention. Itwill be understood that each block of the flowchart illustrations and/orblock diagrams, and combinations of blocks in the flowchartillustrations and/or block diagrams, can be implemented by computerprogram instructions. These computer program instructions may beprovided to a processor of a general purpose computer, special purposecomputer, or other programmable data processing apparatus to produce amachine, such that the instructions, which execute via the processor ofthe computer or other programmable data processing apparatus, createmeans for implementing the functions/acts specified in the flowchartand/or block diagram block or blocks.

These computer program instructions may also be stored in acomputer-readable memory that can direct a computer or otherprogrammable data processing apparatus to function in a particularmanner, such that the instructions stored in the computer-readablememory produce an article of manufacture including instruction meanswhich implement the function/act specified in the flowchart and/or blockdiagram block or blocks.

The computer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions/acts specified inthe flowchart and/or block diagram block or blocks.

As noted earlier, publisher/subscriber systems, and particularly messagebrokers in such systems, maintain device availability information thatis currently available only to devices that implement apublish/subscribe interface

The present invention is a solution that enables an IP network device todetermine the status of a publish/subscribe device that is not directlyvisible to the IP network device through a lookup operation performedusing a publish/subscribe interface. The lookup operation supports aPING operation initiated by a requesting device, as will be described inmore detail below

The invoked lookup operation is described below with reference to FIG.3. It is assumed that an IP network device (not shown) wants todetermine the status of a publish/subscribe device “A” owned byCompanyX.org but cannot obtain the desired information directly. Thenetwork device sends a request for the device A.CompanyX.org to a domainname server 310 associated with CompanyX.org where it is received byreceiver component 330. Device A may be one of several devices A, B, Cand D that are owned by CompanyX.org and that periodically publish theirstatus to a status topic stored in a topic space 380 maintained atmessage broker 370.

The topic space 380 contains a tree structure that represents devicestatus information. In an exemplary embodiment, the tree comprises a“status” root node and a plurality of child nodes. Each child noderepresents a publish/subscribe device (device A=dA; device B=dB; deviceC=dC; and device D=dD). Each device publishes a “1” to the appropriatechild node when it comes “online” and publishes a “0” when it goes“offline”. Therefore, when device A comes online, it publishes a “1” totopic status dA. Message broker 370 retains the last publicationreceived on each status topic and thereby knows whether a device isclassified as “online” or “offline”. Of course, a device may fail ratherthan intentionally go “offline”. When this happens, the message broker370 can detect that the connection to the device is broken and thereforethat the device is “offline”. In this instance, message broker 370itself publishes a “0” to the appropriate status topic.

When a request is received for the status of A.CompanyX.org, one of thedevices owned by CompanyX.org, a mapper component 320 maps the requestto a status topic within topic space 380. Mapper component 320 uses datain a database 360 to resolve the provided address for A.CompanyX.org totopic status dA maintained in the topic space 380 of message broker 370.A status query component 340 then queries the status of thepublish/subscribe device via the publish/subscribe interface of messagebroker 370 by setting up a subscription to the appropriate topic (e.g.status dA). Such a subscription causes message broker 370 to send thelast publication (retained publication) received on that topic to thedomain name server 310. The domain name server 210 can then eitherremain subscribed to the topic in order to be able to more quickly fillfuture requests (e.g. from a local cache) or can immediately unsubscribefrom the status topic.

In another embodiment, the domain name server 310 may subscribe inadvance to topics maintained in topic space 380 for allpublish/subscribe devices that it intends to monitor and maintain atable of status information gleaned from the last received publicationfor each device. Such a table would, of course, be periodically updatedto reflect changes in the current status of the monitoredpublish/subscribe devices.

Status query component 340 uses the retrieved retained publicationinformation to determine whether the queried device (i.e.,A.CompanyX.org) is “online” or “offline”. If the retained publicationcontains a “1”, then the queried device is considered to be “online”. Ifthe retained publication contains a “0”, then the queried device isconsidered to be “offline”.

For an “online” device, status query component 340 instructs the addressreturner component 350 to return an IP address of a device which therequesting device can contact for an online status indication. In theillustrated embodiment, the IP address of the good machine is shown as1.2.3.1. This may be the address of the domain name server 310 itself(since server 310 is known to be online and contactable by therequester) or an entirely separate machine. The fact that an IP addressis returned at all is an indication the publish/subscribe device isonline.

If the publish/subscribe query of the status topic dA indicatesA.CompanyX.org is “offline” or unreachable, status query component 340instructs address returner component 350 to return a known “bad”address. In the illustrated embodiment, the known “bad” IP address ofthe uncontactable machine is shown as 1.2.3.2. When a PING is sent tothe known “bad” IP address, the requesting machine will time outindicating the sought publish/subscribe device is unreachable.

Both the good and the bad returned addresses are preferably associatedwith the domain over which the owner of domain name server hasjurisdiction in order to assure that the good and the bad returnedaddresses will remain good and bad, respectively. A returned bad machineaddress could be an unallocated address in the same IP subnet of thedomain name server 310, which is under administrative control of thedomain name server owner, which can ensure the address will remainunallocated.

FIG. 4 is a representation of the process discussed above in flowchartform. In initial operation 400, a request is received for informationabout a specific publish/subscribe device; i.e., A.CompanyX.org, thatcannot be contacted directly by the requesting device. The receivedrequest is mapped in operation 410 to an A.CompanyX.org status topic dAmaintained by the message broker and a query 420 is generated toretrieve availability information stored in that status topic. If anoperation 430 shows that A.CompanyX.org is currently offline orotherwise unreachable, a “bad” IP address is returned to the requesterin an operation 440. If the operation 430 shows that A.CompanyX.org iscurrently online, a “good” IP address is returned to the requester inoperation 450. The use of the publish/subscribe interface ends at thispoint The requester will not know whether the IP address returnedthrough the use of the publish/subscribe interface is “good”(representing an online publish/subscribe device) or “bad” (representingan offline publish/subscribe device). The requesting device must employa PING process in order to complete the device status query. FIG. 5 is aflow chart of operations that are performed at a requesting device,including the necessary PING process.

Initial operation 510 is the request made by the requesting device tothe publish/subscribe interface and described previously with referenceto FIGS. 3 and 4. Operation 520 is the receipt of an IP address from thepublish/subscribe domain name server. At this point, the requestingdevice will not yet know whether the received IP address is “good” or“bad”. The requesting device employs a conventional PING operation 530of the type described above by sending a series of PING messages to theIP address returned from the publish/subscribe domain name server. Ifoperation 540 indicates that appropriate responses (IP address plusresponse time) are returned, the conclusion is that the deviceassociated with the query is online. If operation 540 indicates that noresponses or inappropriate responses are returned, the conclusion isthat the device associated with query is offline.

The present invention is not necessarily limited to environmentsincluding the use of PING processes, IP requesting devices andpublish/subscribe interfaces. Other uses include representing a person'sonline status with respect to, for example, an instant messaging systemor connected using a mobile application. The querying device may nothave the appropriate software to directly contact the device but may beable to use basic, ubiquitous software such as PING to discover adevice's status indirectly. In such a solution an intermediary DNS isable to query the device and to return one of a good and bad address tothe requester.

Further, it is envisaged the invention may be used to enable a regularIP network management tool to monitor remote devices which are notdirectly accessible to the network management tool, including remotedevices on a non-IP network. The network management tool would usestandard alerting and notification systems to inform a requester that adevice (rather than a network host) had gone offline.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved. It will also be notedthat each block of the block diagrams and/or flowchart illustration, andcombinations of blocks in the block diagrams and/or flowchartillustration, can be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions.

The terminology used herein is for the purpose of describing particularembodiments only and is not intended to be limiting of the invention. Asused herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”and/or “comprising,” when used in this specification, specify thepresence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof.

The corresponding structures, materials, acts, and equivalents of allmeans or step plus function elements in the claims below are intended toinclude any structure, material, or act for performing the function incombination with other claimed elements as specifically claimed. Thedescription of the present invention has been presented for purposes ofillustration and description, but is not intended to be exhaustive orlimited to the invention in the form disclosed. Many modifications andvariations will be apparent to those of ordinary skill in the artwithout departing from the scope and spirit of the invention. Theembodiment was chosen and described in order to best explain theprinciples of the invention and the practical application, and to enableothers of ordinary skill in the art to understand the invention forvarious embodiments with various modifications as are suited to theparticular use contemplated.

Having thus described the invention of the present application in detailand by reference to preferred embodiments thereof, it will be apparentthat modifications and variations are possible without departing fromthe scope of the invention defined in the appended claims.

1. A method for enabling a first computer network device to determinewhether a second computer network device has an online status or anoffline status where the first computer network device cannot directlycontact the second computer network device, the method comprising:receiving a request from the first computer network device for thestatus of the second computer network device; determining whether thesecond computer network device is online or offline; in response to adetermination that the second computer network device is online,returning a first network address to the first computer network device;and in response to a determination that the second computer networkdevice is offline, returning a second network address to the firstcomputer network device.
 2. The method of claim 1, wherein the secondcomputer network device is a publish/subscribe device and whereindetermining whether the second computer network device is online oroffline further comprises mapping the received request to a status topicassociated with the second device.
 3. The method of claim 2, whereindetermining whether the second computer network device is online oroffline further comprises: subscribing to the status topic associatedwith the second computer network device; and receiving statusinformation from the subscribed status topic.
 4. The method of claim 3wherein determining whether the second computer network device is onlineor offline further comprises: associating status information having afirst value to an online status; and associating status informationhaving a second value to an offline status.
 5. The method of claim 4further comprising storing received status information for the seconddevice locally.
 6. A computer program product for enabling a firstcomputer network device to determine whether a second computer networkdevice has an online status or an offline status where the firstcomputer network device cannot directly contact the second computernetwork device, the computer program product comprising a computerusable medium having computer usable program code embodied therewith,the computer usable program code comprising: computer usable programcode configured to receive a request from the first computer networkdevice for the status of the second computer network device; computerusable program code configured to determine whether the second computernetwork device is online or offline; computer usable program codeconfigured to, in response to a determination that the second computernetwork device is online, return a first network address to the firstcomputer network device; and computer usable program code configured, toin response to a determination that the second computer network deviceis offline, return a second network address to the first computernetwork device.
 7. The computer program product of claim 6, wherein thesecond computer network device is a publish/subscribe device and whereinthe computer usable program code configured to determine whether thesecond computer network device is online or offline further comprisescomputer usable program code configured to map the received request to astatus topic associated with the second device.
 8. The computer programproduct of claim 7, wherein the computer usable program code configuredto determine whether the second computer network device is online oroffline further comprises: computer usable program code configured tosubscribe to the status topic associated with the second computernetwork device; and computer usable program code configured to receivestatus information from the subscribed status topic.
 9. The computerprogram product of claim 8 wherein the computer usable program codeconfigured to determine whether the second computer network device isonline or offline further comprises: computer usable program codeconfigured to associate status information having a first value to anonline status; and computer usable program code configured to associatestatus information having a second value to an offline status.
 10. Thecomputer program product of claim 9 further comprising computer usableprogram code configured to store received status information for thesecond computer network device locally.
 11. An apparatus for enabling afirst computer network device to determine whether a second computernetwork device has an online status or an offline status where the firstcomputer network device cannot directly contact the second computernetwork device to determine the status of the second computer networkdevice, the apparatus comprising: a receiver component for receiving arequest from the first computer network device for the status of thesecond computer network device, said request including a second computernetwork device identifier; a data storage component for storing statusdata; a mapping component for mapping the second computer network deviceidentifier to an associated status data storage location in the datastorage component; a status query component for obtaining data stored inthe associated status data storage location; an address returningcomponent for returning a first network address if the obtained data hasa first value and a second network address if the obtained data as asecond value.
 12. The apparatus of claim 11 wherein said first networkaddress is associated to a reachable computer network device and saidsecond network address is associated to an unreachable computer networkdevice.
 13. The apparatus of claim 11 wherein said data storagecomponent comprises topic space maintained by a message broker and apublish/subscribe system and said associated status data storagelocation comprises a status topic associated to said second computernetwork device.
 14. The apparatus of claim 13 wherein said data storagecomponent comprises topic space maintained by a message broker and apublish/subscribe system and said associated status data storagelocation comprises a status topic associated to said second computernetwork device.
 15. The apparatus of claim 14 wherein said the statusquery component further comprises: a subscription component forestablishing a subscription to said associated status topic associatedto said second computer network device; and a message receivingcomponent for receiving information currently stored in said associatedstatus topic.
 16. The apparatus of claim 15 further comprising logic fordetermining whether the information received by the message receivingcomponent has said first value indicative of an online device status orsaid second value indicative of an off-line device status.
 17. Theapparatus of claim 16 further comprising a local memory component forretaining the information received by said message receiving component.